Internet Engineering Task Force (IETF) S. Krishnan 


Request for Comments: 6496 Ericsson 
Category: Experimental J. Laganier 
ISSN: 2070-1721 Juniper Networks 

M. Bonola 


Rome Tor Vergata University 
A. Garcia-Martinez 

UC3M 

February 2012 


Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) 


Abstract 


SEcure Neighbor Discovery (SEND) specifies a method for securing 
Neighbor Discovery (ND) signaling against specific threats. As 
defined today, SEND assumes that the node sending an ND message is 
the owner of the address from which the message is sent and/or 
possesses a key that authorizes the node to act as a router, so that 
it is in possession of the private key or keys used to generate the 
digital signature on each message. This means that the Proxy ND 
signaling performed by nodes that do not possess knowledge of the 
address owner’s private key and/or knowledge of a router’s key cannot 
be secured using SEND. This document extends the current SEND 
specification in order to secure Proxy ND operation. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 
evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering 


Task Force (IETF). It represents the consensus of the IETF 
community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6496. 
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Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
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1. Introduction 


SEcure Neighbor Discovery (SEND) [RFC3971] specifies a method for 
securing Neighbor Discovery (ND) signaling [RFC4861] against specific 
threats [RFC3756]. As defined today, SEND assumes that the node 
sending an ND message is the owner of the address from which the 
message is sent and/or possesses a key that authorizes the node to 
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act as a router, so that it is in possession of the private key or 
keys used to generate the digital signature on each message. This 
means that the Proxy ND signaling performed by nodes that do not 
possess knowledge of the address owner’s private key and/or knowledge 
of a router’s key cannot be secured using SEND. 


This document extends the current SEND specification with support for 
Proxy ND. From this point on, we refer to such an extension as 
"Secure Proxy ND Support for SEND". 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Terminology 
Secure ND Proxy 
A node acting on behalf of another node and authorized to secure a 
Neighbor Discovery Protocol (NDP) message without knowing the 
private key related to the source address of the other node or the 
key related to the router authorization. 


Proxied IPv6 address 


An IPv6 address that does not belong to the Secure ND Proxy and 
for which the Secure ND Proxy is performing advertisements. 


Non-SEND node 
An IPv6 node that does not implement the SEND [RFC3971] 
specification but uses the ND protocol defined in [RFC4861] and 
[RFC4862], without additional security. 

RFC 3971 node 
An IPv6 node that does not implement the specification defined in 


this document for Secure Proxy ND support but uses the SEND 
specification as defined in [RFC3971]. 


Secure Proxy ND (SPND) node 


An IPv6 node that receives and validates messages according to the 
specification defined in this document for Secure Proxy ND 
support. 
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Translated NDP message 


An NDP message issued by a Secure ND Proxy as a result of a 
received NDP message originated by the owner of the address or 
originated by another node acting on behalf of the owner of the 
address. 


Synthetic NDP message 


An NDP message issued by a Secure ND Proxy that is not the result 
of a received NDP message. 


4. Secure Proxy ND Overview 


The original SEND specification [RFC3971] has implicitly assumed that 
only the node sending an ND message is the owner of the address from 
which the message is sent. This assumption does not allow proxying 
of ND messages, since the advertiser is required to generate a valid 
RSA Signature option, which in turn requires possession of the 
public-private key pair that was used to generate a Cryptographically 
Generated Address (CGA), or that was associated to a router 
certificate. 


To be able to separate the roles of owner and advertiser, the 
following extensions to the SEND protocol are defined: 


o A Secure Proxy ND certificate, which is a certificate authorizing 
an entity to act as an ND proxy. It is an X.509v3 certificate in 
which the purpose for which the certificate is issued has been 
specified explicitly, as described in a companion document 
[RFC6494]. Briefly, Secure Proxy ND certificates include one or 
more KeyPurposeld values that can be used for authorizing proxies 
to sign Router Advertisement (RA) and Redirect messages, or to 
sign Neighbor Advertisement (NA), Neighbor Solicitation (NS), or 
Router Solicitation (RS) messages on behalf of other nodes. The 
inclusion of this value allows the certificate owner to perform 
proxying of SEND messages for a range of addresses indicated in 


the same certificate. This certificate can be exchanged through 
the Authorization Delegation Discovery process defined in 
[RFC3971]. 


o A new Neighbor Discovery option called the Proxy Signature (PS) 
option. This option contains the hash value of the public key of 
the proxy, and the digital signature of the SEND message computed 
with the private key of the proxy. The hash of the public key of 
the proxy is computed over the public key contained in the Secure 
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Proxy ND certificate. When an ND message contains a PS option, it 
MUST NOT contain CGA or RSA Signature options. The PS option MUST 
be appended to any NDP message (NA, NS, RS, RA, and Redirect) to 
secure it. 


o A modification of the SEND processing rules for all ND messages: 
NA, NS, RS, RA, and Redirect. When any of these messages 
containing a PS option is validated, it is considered secure. 


These extensions are applied in the following way: 


o A Secure ND Proxy that proxies ND messages on behalf of a node can 


use the PS option to protect the proxied messages. This Secure ND 
Proxy becomes part of the trusted infrastructure just like a SEND 
router. 


o The messages to be secured with the PS option are built according 
to [RFC4861] if they are synthesized by the Secure ND Proxy, or 
they result from the processing rules defined in [RFC4389] if they 
are translated ND messages. 


o In order to allow nodes to successfully validate secured proxied 
messages, the nodes MUST be aware of the Secure Proxy ND 
certificate (in the format described in [RFC6494]) and MUST apply 
the modified processing rules specified in this document. We call 
these nodes ’SPND nodes’. Note that the rules for generating ND 
messages in SPND nodes do not change, so these nodes behave as 
defined in [RFC3971] when they send ND messages. 


o To allow SPND nodes to know the certification path required to 
validate the public key of the proxy, devices responding to CPS 
(Certification Path Solicitation) messages with CPA (Certification 
Path Advertisement) messages as defined in Section 6 of the SEND 
specification [RFC3971] are extended to support the certificate 
format specified in [RFC6494], and are configured with the 
appropriate certification path. 


5. Secure Proxy ND Specification 


A Secure ND Proxy performs all the operations described in the SEND 
specification [RFC3971] with the addition of new processing rules to 
ensure that the receiving node can identify an authorized proxy 
generating a translated or synthetic SEND message for a proxied 
address. 


This is accomplished by signing the message with a private key of the 
authorized Secure ND Proxy. The signature of the Secure ND Proxy is 
included in a new option called the PS option. The signature is 
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performed over all the Neighbor Discovery Protocol (NDP) options 
present in the message, and the PS option is appended as the last 
option in the message. 


5.1. Proxy Signature Option 


The Proxy Signature option allows signatures based on public keys to 
be attached to NDP messages. The format of the PS option is 
described in the following diagram: 


0 1 2 3 
Ord. (22 34 SOF Be Oo 0 aT 2 Be A 5 OT 8 Os Oe 1 22 3 Ae O 7 289 OT 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++ 

| Type | Length | Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


Key Hash 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Digital Signature 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Padding 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 1: PS Option Layout 

Type 
32 

Length 
The length of the option (including the Type, Length, Reserved, 


Key Hash, Digital Signature, and Padding fields) in units of 
8 octets. 
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Reserved 


A 16-bit field reserved for future use. The value MUST be 
initialized to zero by the sender, and MUST be ignored by the 
receiver. 


Key Hash 


A 128-bit field containing the most significant (leftmost) 

128 bits of a SHA-1 [SHA1] hash of the public key used for 
constructing the signature. Its purpose is to associate the 
signature to a particular key known by the receiver. Such a key 
MUST be the same one within the corresponding Secure Proxy ND 
certificate. 


Digital Signature 
A variable-length field containing a PKCS#1 v1.5 signature, 
constructed by using the sender’s private key over the following 


sequence of octets: 


1. The 128-bit CGA Message Type tag [RFC3972] value for Secure 


Proxy ND, 0Ox09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. (The tag 
value has been generated randomly by the editor of this 
specification.) 


2. The 128-bit Source Address field from the IP header. 


3. The 128-bit Destination Address field from the IP header. 


4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from 
the ICMP header. 


5. The NDP message header, starting from the octet after the ICMP 
Checksum field and continuing up to, but not including, NDP 
options. 


6. All NDP options preceding the Proxy Signature option. 


The signature value is computed with the RSASSA-PKCS1-v1_5 
algorithm and SHA-1 hash, as defined in [RSA]. This field starts 
after the Key Hash field. The length of the Digital Signature 
field is determined by the ASN.1 BER coding of the PKCS#1 v1.5 
signature. 
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Padding 
This variable-length field contains padding. The length of the 
padding field is determined by the length of the Proxy Signature 
option minus the length of the other fields. 
Modified SEND Processing Rules 


This specification modifies the sender and receiver processing rules 
defined in the SEND specification [RFC3971]. 


1. Processing Rules for Senders 


A Secure ND Proxy MUST NOT use a key to sign NDP message types that 
do not correspond to the authorization granted to the considered key. 
NA, NS, and RS messages MUST be signed with a key corresponding to a 
Secure Proxy ND certificate with a KeyPurposeId value [RFC6494] of 
id-kp-sendProxiedOwner, and the source addresses of the messages MUST 
be encompassed in the prefix associated to the certificate. RA and 
Redirect messages MUST be signed with a key corresponding to a Secure 
Proxy ND certificate with a KeyPurposelId value of 
id-kp-sendProxiedRouter. The prefix included in the RA message for 
on-link determination and/or stateless address autoconfiguration, and 
the Target Address of the Redirect message, MUST be encompassed in 
the prefix associated to that certificate. 


A secured NDP message sent by a Secure ND Proxy for a proxied address 
MUST contain a PS option and MUST NOT contain either CGA or RSA 
Signature options. Section 7 discusses in which cases an NDP message 
has to be secured in a scenario including non-SEND nodes. 


The input of this process is a message obtained in either of the 
following ways: 


a. If the Secure ND Proxy generates synthetic SEND messages for a 
proxied address, the message MUST be constructed as described in 
the Neighbor Discovery for IP version 6 specification [RFC4861]. 


b. If the Secure ND Proxy translates secured messages, first the 
authenticity of the intercepted message MUST be verified. If the 
intercepted message is a SEND message, it MUST be validated as 
specified in Section 5 of the SEND specification [RFC3971]. If 
the intercepted message contains a PS option, the authenticity of 
the message MUST be verified as detailed in Section 5.2.2 of this 
specification. After validation, the CGA, RSA, or PS options of 
the original message MUST be removed. Then, the message to be 
translated MUST be processed according to the ND Proxy 
specification [RFC4389]. In this way, it is determined whether 
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the message received should be proxied or not; the proxy 
interface status is updated if needed, the outgoing interface is 
determined, the link-layer header and the link-layer address 
within the payload are modified if required, etc. 


A Secure ND Proxy then modifies the input message as follows: 


1. Timestamp and Nonce options MUST be included according to the 
rules specified in SEND [RFC3971]. The value in the Timestamp 
option MUST be generated by the proxy. If the proxy is 
translating a message that includes a nonce, the Nonce value in 
the proxied message MUST be the same as in the intercepted 
message. If the proxy is synthesizing a solicitation message, 
the Nonce value MUST be generated by the proxy. If the proxy is 
synthesizing an advertisement message, the Nonce value MUST 
correspond to the solicitation message to which the proxy is 
responding. 


2. The Proxy Signature option MUST be added as the last option in 
the message. 


3. The data MUST be signed as explained in Section 5.1. 
5.2.2. Processing Rules for Receivers 


Any SEND message without a Proxy Signature option MUST be treated as 
specified in the SEND specification [RFC3971]. 


A SEND message including a Proxy Signature option MUST be processed 
as specified below: 


1. The receiver MUST ignore any RSA and CGA options, as well as any 
options that might come after the first PS option. The options 
are ignored for both signature verification and NDP processing 
purposes. 


2. The Key Hash field MUST indicate the use of a known public key. 
A valid certification path (see [RFC6494] Section 9) between the 
receiver’s trust anchor and the sender’s public key MUST be 
known. The Secure Proxy ND X.509v3 certificate MUST contain an 
extended key usage extension including the appropriate 
KeyPurposelId value and prefix for the message to validate: 


* For RA messages, a KeyPurposelId value of 
id-kp-sendProxiedRouter MUST exist for the certificate, and 
the prefix included in the RA message for on-link 
determination and/or stateless address autoconfiguration MUST 
be encompassed in the prefix associated to that certificate. 
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* For Redirect messages, a KeyPurposelId value of 
id-kp-sendProxiedRouter MUST exist for the certificate, and 
the prefix included in the Target Address of the Redirect 
message MUST be encompassed in the prefix associated to that 
certificate. 


* For NA, NS, and RS messages, a KeyPurposeld value of 
id-kp-sendProxiedOwner MUST exist for the certificate, and the 
source addresses of the messages MUST be encompassed in the 
prefix associated to the certificate. 


If any of these tests fail, the verification fails. 


3. The Digital Signature field MUST have correct encoding; 
otherwise, the verification of the message including the PS 
option fails. 


4. The Digital Signature verification MUST show that the signature 
has been calculated as specified in Section 5.1; otherwise, the 
verification of the message including the PS option fails. 


5. The Nonce option MUST be processed as specified in [RFC3971] 
Section 5.3.4, except for replacing ’RSA Signature option’ with 
"PS option’; if these tests fail, the verification of the message 
including the PS option fails. 


6. The Timestamp option MUST be processed as specified in [RFC3971] 
Section 5.3.4, except for replacing ’RSA Signature option’ with 
"PS option’. If these tests fail, the verification of the 
message including the PS option fails. The receiver SHOULD store 
the peer-related timing information specified in [RFC3971] 
Sections 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each 
different proxy (which could be identified by the different Key 
Hash values of the proxied message) and separately from the 
timing information associated to the IP address of a node for 
which the message is proxied. In this way, a message received 
for the first time from a proxy (i.e., for which there is no 
information stored in the cache) for which the Timestamp option 
is checked SHOULD be checked as a message received from a new 
peer (as in [RFC3971] Section 5.3.4.2). 


7. Messages with the Override bit [RFC4861] set MUST override an 
existing cache entry regardless of whether it was created as a 
result of an RSA Signature option or a PS option validation. 
When the Override bit is not set, the advertisement MUST NOT 
update a cached link-layer address created securely by means of 
RSA Signature option or PS option validation. 
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Messages for which the verification fails MUST be silently discarded 
if the node has been configured to accept only secured ND messages. 
The messages MAY be accepted if the host has been configured to 
accept both secured and unsecured messages but MUST be treated as an 
unsecured message. 


5.3. Proxying Link-Local Addresses 


SEND [RFC3971] relies on certificates to prove that routers are 
authorized to announce a certain prefix. However, Neighbor Discovery 
[RFC4861] states that routers do not announce the link-local prefix 
(fe80::/64). Hence, it is not required for a SEND certificate to 
hold an X.509 extension for IP addresses that authorizes the 
fe80::/64 prefix. However, some Secure Proxy ND scenarios 
([RFC4389], [RFC5213]) impose providing the proxying function for the 
link-local address of a node. When Secure ND Proxy functionality for 
a link-local address is required, either a list of link-local 
addresses, or the fe80::/64 prefix MUST be explicitly authorized to 
be proxied in the corresponding certificate. 


6. Application Scenarios 


In this section, we describe three different application scenarios 
for which Secure Proxy ND support for SEND can be applied. Note that 
the particular way in which Secure Proxy ND support is applied (which 
ND messages are proxied, in which direction, how the interaction with 
non-SEND hosts and RFC 3971 hosts is handled, etc.) largely depends 
on the particular scenario considered. In the first two scenarios 
presented below, ND messages are synthesized on behalf of off-link 
nodes. In the third one, ND messages are translated from the 
messages received in other interfaces of the proxy. 


6.1. Scenario 1: Mobile IPv6 


The description of the problems for deploying SEND in this scenario 
is presented in [RFC5909]. 


The Mobile IPv6 (MIPv6) protocol [RFC6275] allows a Mobile Node (MN) 
to move from one link to another while maintaining reachability at a 
stable address, the so-called MN’s Home Address (HOA). When an MN 
attaches to a foreign network, all the packets sent to the MN’s HoA 
by a Correspondent Node (CN) on the home link or a router are 
intercepted by the Home Agent (HA) on that home link, encapsulated, 
and tunneled to the MN’s registered Care-of Address (CoA). 


To deploy Secure Proxy ND in this scenario, i.e., to secure the HA 
operation, a Secure Proxy ND certificate with a KeyPurposelId value of 
id-kp-sendProxiedOwner for the prefix of the home link is required. 
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The Secure ND Proxy is configured with the private key associated to 
this certificate. When a NS is intercepted by the HA on the home 
link, the HA checks whether the Target Address within the NS matches 
with any of the MN’s Home Addresses in the binding cache, and if so, 
it replies with a Neighbor Advertisement (NA) constructed as 
described in [RFC4861], containing its own link-layer address (HA_LL) 
as the Target Link-Layer Address Option (TLLAO). Then, a timestamp 
(generated by the proxy) and nonce (if appropriate, according to 
[RFC3971]) MUST be included. Finally, a PS option signing the 
message MUST be included as the last option of the message. 


Node (N) Home Agent (HA) Mobile Node (MN) 
on Home Link on Home Link on Foreign Link 
SRC = N 
DST = solicited_node (MN) 
ICMPv6 NS 


SLLAO = N_LL 


| 
TARGET = MN | 
| 
[CGA] | 

| 


RSA signature 


| 

| 

| 

| 

| SRC = HA 

| DST = N 

| ICMPv6 NA 

| TARGET = MN 
TLLAO = HA_LL 
PS signature 

| 

| 

| 

| 

| 

| 

| 


traffic 
dest = MN HoA 


| tunneled traffic 
| dest = MN CoA 


Figure 2: Proxy ND Role of the Home Agent in MIPv6 


A node receiving the NA containing the PS option (e.g., the CN in the 
home link, or a router) MUST apply the rules defined in 

Section 5.2.2. Note that in this case the Override bit of the NA 
message is used to control which messages should prevail on each 
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case: the message generated by the proxy when the MN moves from the 
home network, or the MN if it comes back to the home link, as defined 
in the MIPv6 specification [RFC6275]. 


6.2. Scenario 2: Proxy Mobile IPv6 


Proxy Mobile IPv6 [RFC5213] is a network-based mobility management 
protocol that provides IP mobility management support for MNs without 
requiring that MNs be involved in the mobility-related signaling. 

The IP mobility management is totally hidden to the MN in a Proxy 
Mobile IPv6 domain, and it is performed by two functional entities: 
the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). 


When the MN connects to a new access link, it sends a multicast 
Router Solicitation (RS). The MAG on the new access link, upon 
detecting the MN’s attachment, signals the LMA requesting an update 
of the binding state of the MN (by means of a Proxy Binding Update 
(PBU)). Once the signaling is completed (it receives a Proxy Binding 
Ack (PBA)), the MAG replies to the MN with a Router Advertisement 

(RA) containing the home network prefix(es) that were assigned to 
that mobility session, making the MN believe it is still on the same 
link, so the IPv6 address reconfiguration procedure is not triggered 
(Figure 3). 
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MN new MAG LMA 


MN Attached 


MN Attached Event from MN/Network 


| 
| 
| | 
SRC = MN | 
DST = all routers | | 
ICMPv6 RS | 
[CGA] 
RSA signature | | 
--------------------- >| | 
| | 
|--- PBU ------------- > | 
| | 
| Accept PBU 
| <------------- PBA --- 
| 


Accept PBA 


=== Bi-Dir Tunnel == 


DST = MN 
ICMPv6 RA 

SLL = MAG_LL 
PS | 


| 
SRC = MAG4MN | 
| 
| 
| 


| | 
| | 
| | 
Figure 3: Mobile Node’s Handover in PMIPv6 


To avoid potential link-local address collisions between the MAG and 
the MN after a handoff to a new link, the Proxy Mobile IPv6 
specification [RFC5213] requires that the MAG’s link-local address on 
the link to which the MN is attached be generated by the LMA when the 
MN first attaches to a PMIPv6 domain, and be provided to the new MN’s 
serving MAG after each handoff. Thus, from the MN’s point of view, 
the MAG’s link-local address remains constant for the duration of 
that MN’s session. 
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The approach described above and the current SEND specification are 

incompatible, since sharing the same link-local address on different 
MAGs would require all MAGs of a PMIPv6 domain to construct the CGA 
and the RSA Signature option with the same public-private key pair, 

which is not an acceptable security policy. 


Using different public-private key pairs on different MAGs would mean 
that different MAGs use different CGAs as link-local addresses. 

Thus, the serving MAG’s link-local address would change after each 
handoff of the MN, which is in contradiction with the way MAG link- 
local address assignment occurs in a PMIPv6 domain. 


To provide SEND protection, each MAG MUST be configured to act as a 
proxy by means of a certificate associated to the PMIPv6é domain, 
authorizing each MAG to securely proxy NA and RS messages by means of 
a KeyPurposeld value of id-kp-sendProxiedOwner. In addition, the 
certificate MUST also authorize the MAG to advertise prefixes by 
associating to the same certificate a KeyPurposelId value of 
id-kp-sendProxiedRouter. Note that the inclusion of multiple 
KeyPurposeld values is supported by [RFC6494]. 


When a MAG replies to an RS with an RA, the source address MUST be 
equal to the MAG link-local address associated to the MN in this 
PMIPv6 domain, with its own link-layer address as the source link- 
layer address. Then, a timestamp (generated by the proxy) and nonce 
(if appropriate, according to [RFC3971]) MUST be included. Finally, 
a PS option signing the message MUST be included as the last option 
of the message. This procedure is followed for any other ND message 
that could be generated by the MAG to the MN. 


A node receiving a message from the MAG containing the PS option MUST 
apply the processing rules defined in Section 5.2.2. Note that 
unsolicited messages sent by the MAG should be validated by the host 
according to timestamp values specific to the MAG serving the link, 
not to any other MAG to which the host has been connected before in 
other links, according to processing step number 6 of Section 5.2.2. 
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6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy 


The problems for deploying SEND in this scenario are presented in 


[RFC5909]. 
Link 1 Link 2 
Host A ND Proxy (P) Host B 

SRC = A | 

| DST = solicited_node (B) | 
| ICMPv6 NS | | 
| TARGET = B | | 
| SLLAO = A LL | | 
|----------=-------------- >| | 

SRC = A 

| | DST = solicited_node (B) | 
| | ICMPv6 NS | 
| | TARGET = B | 
| | SLLAO = P_LL | 
| —— a >| 
| | SRC = B | 
| | DST =A | 
| | ICMPv6 NA | 
| | TARGET = B | 
| | TLLAO = B_LL | 
< aa al at ae a ge Sad a et an a See a ees Se a ee 
| SRC = B | 
| DST =k | | 
| ICMPv6 NA | | 
| TARGET = B | | 
| TLLAO = P_LL | | 
D | | 


Figure 4: RFC 4389 Neighbor Discovery Proxy Operation 


The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a 
method by which multiple link-layer segments are bridged into a 
single segment and specifies the IP-layer support that enables 
bridging under these circumstances. 


A Secure ND Proxy MUST parse any IPv6 packet it receives on a proxy 
interface to check whether it contains one of the following NDP 
messages: NS, NA, RS, RA, or Redirect. The Secure ND Proxy MUST 
verify the authenticity of the received ND message, according to 
[RFC3971], or according to Section 5.2.2 if it contains a PS option. 
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Then, after removing the CGA, RSA, or PS options, the message to be 
translated MUST be processed according to the ND Proxy specification 
[RFC4389]. This includes performing loop prevention checks, 
determining the outgoing interface for the proxied message, changing 
the source link-layer address to the address of the outgoing 
interface, changing source link-layer addresses contained in the 
payload (that is, in a Source Link-Layer Address Option (SLLAO) or a 
Target Link-Layer Address Option (TLLAO)), maintaining the 
destination link-layer address as the address in the neighbor entry 
corresponding to the destination IPv6 address, setting the P bit for 
proxied RA messages, etc. Note that besides link-layer addresses and 
the P bit of a RA, no other field of the received message is changed 
when proxied by an [RFC4389] proxy. 


When any other IPv6 unicast packet is received on a proxy interface, 
if it is not locally destined, then it is forwarded unchanged (other 
than using a new link-layer header) to the proxy interface for which 
the next-hop address appears in the neighbor cache. If no neighbor 
cache entry is present, the Secure ND Proxy SHOULD queue the packet 
and initiate a Neighbor Discovery signaling as if the NS message were 
locally generated. 


Note that to be able to sign any NS, NA, RS, RA, or Redirect message, 
the key used MUST correspond to a certificate with KeyPurposelId 
values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. 


In order to deploy this scenario, nodes in proxied segments MUST know 
the certificate-authorizing proxy operation. To do so, it could be 
required that at least one device per proxied segment (maybe the 
proxy itself) be configured to propagate the required certification 
path to authorize proxy operation by means of a CPS/CPA exchange. 


7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes 


In this section, we discuss the interaction of Secure ND Proxies and 
SPND nodes with RFC 3971 nodes and non-SEND nodes. As stated in 
[RFC3971], network operators may want to run a mixture of nodes 
accepting secured and unsecured NDP messages at the same time. 
Secure ND Proxies and SPND nodes SHOULD support the use of secured 
and unsecured NDP messages at the same time. 


7.1. Backward Compatibility with RFC 3971 Nodes 


RFC 3971 nodes, i.e., SEND nodes not compliant with the modifications 
required in Section 5, cannot correctly interpret a PS option 

received in a proxied ND message. These SEND nodes silently discard 
the PS option, as specified in [RFC4861] for any unknown option. As 
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a result, these messages will be treated as unsecured, as described 
in Section 8 ("Transitions Issues") of the SEND specification 
[RFC3971]. 


When RFC 3971 nodes and SPND nodes exchange ND messages (without 
proxy intervention), in either direction, messages are generated 
according to the SEND specification [RFC3971], so these nodes 
interoperate seamlessly. 


In the scenarios in which the proxy translates ND messages, the 
messages to translate can either be originated in an RFC 3971 node or 
in an SPND node, without interoperability issues (note that the 
difference between RFC 3971 nodes and SPND nodes only affects the 
ability to process received NDP messages containing a PS option, not 
the way they generate messages secured by SEND). 


A configuration option MAY exist in a Secure ND Proxy to specify the 
RFC 3971 nodes to which it is connected, so that the proxied messages 
sent to these nodes are not processed according to the Secure Proxy 
ND specification, for performance reasons. 


7.2. Backward Compatibility with Non-SEND Nodes 


Non-SEND nodes receiving NDP packets silently discard PS options, as 
specified in [RFC4861] for any unknown option. Therefore, these 
nodes interpret messages proxied by a Secure ND Proxy as any other ND 
message. 


When non-SEND nodes and SPND nodes exchange ND messages (without 
proxy intervention), in either direction, the rules specified in 
Section 8 of [RFC3971] apply. 


A Secure ND Proxy SHOULD support the use of secured and unsecured NDP 
messages at the same time, although it MAY have a configuration that 
causes proxying to not be performed for unsecured NDP messages. A 
Secure ND Proxy MAY also have a configuration option whereby it 
disables secure ND proxying completely. This configuration SHOULD be 
switched off by default; that is, security is provided by default. 

In the following paragraphs, we discuss the recommended behavior of 
the Secure ND Proxy regarding the protection level to provide to 
proxied messages in a mixed scenario involving SPND/RFC 3971 nodes 
and non-SEND nodes. In particular, two different situations occur, 
depending on whether the proxied nodes are RFC 3971 or SPND nodes, or 
non-SEND nodes. 


As a rule of thumb, if the proxied nodes can return to the link in 
which the proxy operates, the Secure ND Proxy MUST only generate PS 
options on behalf of nodes with SEND capabilities (i.e., those nodes 
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that could use SEND to defend their messages if present on the same 
link as the proxy -- in other words, either RFC 3971 nodes or SPND 
nodes). This is relevant to allow nodes to prefer secured 
information over an unsecured one, and to properly execute the 
Duplicate Address Detection (DAD) procedure, as specified in 
[RFC3971]. Therefore, in this case, the Secure ND Proxy MUST 
synthesize/translate messages containing the PS option for SPND and 
RFC 3971 hosts, and MUST NOT synthesize/translate messages containing 
the PS option for non-SEND nodes. Note that ND advertisements in 
response to solicitations generated by a Secure ND Proxy must either 
be secured or not secured, according to the previous considerations 
(i.e., according to the nature of the proxied node), and not 
according to the secure or unsecure nature of the solicitation 
message. 


In order to apply this rule, the Secure ND Proxy needs to know the 


security capabilities of the proxied node. The way this information 
is acquired depends on the application scenario, and it is discussed 
next: 


o For scenarios in which ND messages are translated for nodes that 
can arrive to the link in which the proxy operates, the rule can 
be easily applied: only for messages validated in the Secure ND 
Proxy according to the SEND specification [RFC3971], or according 
to Section 5.2.2 of this specification for messages containing a 
PS option (which means that another proxy previously checked that 
the original message was secured), the message MUST be proxied 
securely by the inclusion of a PS option. Unsecured ND messages 
could be proxied if unsecured operation is enabled in the proxy, 
but the message generated by the Secure ND Proxy for the received 
message MUST NOT include a PS option. 


o For scenarios in which ND messages are synthesized on behalf of 
remote nodes, different considerations should be made according to 
the particular application scenario. 


* For MIPv6, if the MN can return to the home link, it is 
required that the proxy know whether the node could use SEND to 
defend its address or not. A HA including the PS option for 
proxying a non-SEND MN would make ND messages sent by the proxy 
be more preferred than an ND message of the non-SEND MN when 
the MN returns to the home link (even if the proxied messages 
have the Override bit set to 1). Not using the PS option for 
an RFC 3971 or SPND MN would make the address in the home link 
more vulnerable when the MN is away than when it is in the home 
link, defeating the purpose of the Secure Proxy ND mechanism. 
Therefore, in this case, the HA MUST know the SEND capabilities 
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of the MN, MUST use the PS option if the MN is an SPND or 
RFC 3971 host, and MUST NOT use the PS option for non-SEND 
hosts. 


* For the Proxy Mobile IPv6 scenario, a node moving from a link 
in which the PS option has been used to protect a link-layer 
address to a link in which ND messages are not protected by 
SEND would prevent the MN from acquiring the new information 
until the cached information expires. However, in this case, 
it is reasonable to consider that all MAGs provide the same 
security for protecting ND messages, and that either all MAGs 
or no MAGs will behave as a Secure ND Proxy, so configuration 
is expected to be easier. 


A configuration option MAY exist in a Secure ND Proxy to specify the 
non-SEND nodes to which it is connected, so that the proxied messages 
sent to these nodes are not processed according to the Secure Proxy 
ND specification, for performance reasons. 


8. Security Considerations 


The mechanism described in this document introduces a new PS option 
allowing a Secure ND Proxy to synthesize or translate a SEND message 
for a proxied address, to redirect traffic for given target 
addresses, or to advertise prefix information by means of RA 
messages. An SPND node only accepts such a message if it includes a 
valid PS option generated by a properly authorized Secure ND Proxy 
(with a certificate containing a KeyPurposelId with value 
id-kp-sendProxiedOwner for protecting NA, NS, and RS messages, or 
containing a KeyPurposelId value of id-kp-sendProxiedRouter for 
protecting RA and Redirect messages). Such a message has protection 
against the threats presented in Section 9 of [RFC3971] equivalent to 
a message signed with an RSA Signature option. 


The security of proxied ND messages not including a PS option is the 
same as an unsecured ND message. The security of a proxied ND 
message received by a non-SEND host or RFC 3971 host is the same as 
an unsecured ND message. 


When a message including a PS option is received by an SPND node, any 
CGA or RSA options also included in the message are removed and the 
remaining message further processed. Although properly formed 
proxied messages MUST NOT include PS and CGA/RSA options at the same 
time, discarding them if they appear does not affect security. If 
the PS option is validated, then the information included in the 
message has been validly generated by a proxy, and should be honored 
(remember that anti-replay protection is provided by means of Nonce 
and Timestamp options). If the PS option is not validated, then it 
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is treated as an unsecured message. In any case, there is no gain 
for an attacker from appending false or old CGA/RSA information to a 
message secured by a Secure ND Proxy. 


A compromised Secure ND Proxy provisioned with an authorization 
certificate with a KeyPurposelId value of id-kp-sendProxiedRouter is 
able, like a compromised router, to siphon off traffic from the host, 
or mount a man-in-the-middle attack, for hosts communicating to off- 
link hosts. A compromised Secure ND Proxy provisioned with an 
authorization certificate with a KeyPurposelId value of 
id-kp-sendProxiedOwner can siphon off traffic or mount a man-in-the- 
middle attack for communication between on-link hosts, even if the 
hosts use SEND. Note that different application scenarios may 
require one type of authorization, the other, or both. To minimize 
security risks, authorization capabilities MUST NOT exceed the ones 
strictly required by the application scenario to be deployed. 


The messages for which a Secure ND Proxy performs its function and 
the link for which this function is performed MUST be configured 
appropriately for each proxy and scenario. This configuration is 
especially relevant if Secure Proxy ND is used for translating ND 
messages from one link to another. 


Section 7 discusses the security considerations resulting from the 
decision to append or omit the PS option, depending on the SEND- 
awareness of the proxied nodes. 


Protection against replay attacks from unsolicited messages such as 
NA, RA, and Redirects is provided by means of the Timestamp option. 
When Secure ND Proxy is used, each host, and each proxy acting on 
behalf of that host, are considered to be different peers in terms of 
timestamp verification. Since the information provided by the host 
and a proxy, including different link-layer addresses, may be 
different, a replay attack could affect the operation of a third 
node: replaying messages issued by a host that is no longer in the 
link can prevent the use of a proxy, and replaying messages of a 
proxy when the host is back in the link can prevent communication 
with the host. This kind of attack can be performed until the 
timestamp of the peer (either the host or a proxy) is no longer valid 
for the receiver. The window of vulnerability is in general larger 
for the first message received from a new peer than for subsequent 
messages received from the same peer (see [RFC3971]). A more 
detailed analysis of the possible attacks related to the Timestamp 
option is described in Section 6.3 of [RFC5909]. 
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9. IANA Considerations 


IANA has allocated the following a new IPv6 Neighbor Discovery Option 
type for the PS option, as 32. The value has been allocated from the 
namespace specified in the IANA "IPv6 Neighbor Discovery Option 
Formats" registry located at 
http://www.iana.org/assignments/icmpv6-parameters. 


IANA has also allocated the following new 128-bit value under the 
"Cryptographically Generated Addresses (CGA) Message Type Name Space" 
registry [RFC3972]: 
Ox09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. 
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